IBIS Macromodel Task Group Meeting date: 15 October 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan * Todd Bermensolo Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None ------------- Review of ARs: - Ambrish to look into adding graphic or improved example to BIRD197.5. - Done. - Randy to add "post-process" versus "post process" to the IBIS 7.0 known issues document. - Done. - Walter to send the modified BIRD198 syntax proposal to Bob, Randy, Arpad and Mike L. - Done. - Randy and Michael M. to invite DDR memory and controller vendors to comment on new protocols. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the October 8 meeting. Mike L. moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: BIRD198.1: Walter noted that some email discussions had occurred amongst the private group since the last meeting. He asked what the dominant characteristic of a PDN model is and said that he thought it was the capacitance between the power and ground planes. He noted that this is largely a function of the overlapping area of the planes and the thicknesses and strengths of the dielectrics between the various layers. The capacitance is a function of what's in between the rail planes. The important question is whether there is any correlation between the strength/speed of active transistors and the thicknesses and dielectric constants of all the IC fab layers between the conductive planes for the rails. Walter presented two examples, one of which could be used if there were a correlation, and one of which could be used if there weren't. Example 1 contained a PDN Group with process corners (typ/slow/fast). It contained a model between Vdd and Vss. Walter noted that multiple models could be provided between different rails, but this example focused on a single model within the Group. Values were provided for C_pdn, R_pdn, and R_leak, and these were correlated with the typ/slow/fast I/V curves, so three columns were provided for each value. This is what could be used if the PDN characteristics, largely capacitance, were correlated with the transistor process. Example 2 contained multiple PDN Groups. One was named "Large Cap" and another was name "Small Cap", and there could be many more. The groups themselves could serve as the "corner" cases of the on-die PDN. In this case the model(s) within the groups would provide single values for C_pdn, R_pdn, and R_leak. The model maker could provide as many of these "corner" groups as they wanted. The EDA tool could simply allow the selection of one of the groups, and if it were like Example 1 values would then be selected according to process corner. If it were like Example 2, then the single values would be specified directly. Walter also noted that an EDA tool might provide a "No PDN Group" option in its PDN model selection mechanism. This would allow a user who had a BIRD189 Interconnect model that already contained all the on-die PDN modeling to skip using the PDN Groups altogether. Arpad noted that Example 1 contained 3 columns of values for the parameters according to process corner (typ/slow/fast). He therefore preferred that the Subparam names be C_pdn_corner, R_pdn_corner, and R_leak_corner similar to the [C Comp Corner] keyword. Walter noted that [C Comp] and [C Comp Corner] are keywords, and these _pdn values are Subparams. Arpad acknowledged the difference but still felt it would be much clearer if _corner were used for the PDN parameter names in the correlated (typ/slow/fast) case. Walter agreed and changed the Subparam names in Example 1 to add the _corner suffix. Walter noted that he thought Randy was ready to prepare a response to the authors based on these examples. Randy agreed and noted that the authors are presenting this proposal at the upcoming IBIS Summit in Tokyo, so we want to get them feedback in time for their presentation. Randy noted some of his feedback from the private email discussions. He said that choosing the PDN corner that's going to create best/worst case conditions is complicated. The PDN capacitance is interacting with PDN inductance in the package, and you can get some resonance between those. Depending on the data rate of the signals involved, that resonance could be an issue. So one may have to analyze all sorts of combinations to figure out a best or worst case PDN. Arpad asked if the second example with multiple "corners" would be the way to handle that scenario. Randy agreed, since this wouldn't really be correlated with a process corner, and someone may want to make different selections. Walter said he would send the modified proposal and example to the private email list so Randy could prepare a response to the authors of BIRD198. Randy agreed. DC_Offset BIRD: Ambrish shared a modified version of the BIRD197.5-3 draft he had emailed the ATM list prior to the meeting. He noted that Walter and Fangyi had pointed out confusion that could arise based on his initial version, and he acknowledged that this was true because of cut-and-paste errors introduced while creating the examples from older versions of the draft. Ambrish noted that the example Application Scenarios he had introduced now explicitly explain the ranges of the post-processed waveforms. He noted that the two examples essentially illustrate the same thing, and we could remove one if people felt they were redundant. Fangyi suggested that the statements about post-processed waveform ranges be moved to the end of bullet c (i.e., the end of the explained flow) in both examples. Ambrish agreed that this was much clearer and made the change. Walter agreed. Fangyi noted that this version addressed all the questions he'd raised about the original version. Walter noted that there were still some open issues. He noted two sentences that had been added to the end of the Usage Rules: The Rx AMI_GetWave output waveform returned by the AMI model must be nominally centered around zero Volts. and: The High/Low Threshold of [the] Rx AMI_GetWave output waveform returned by the AMI model shall be zero Volts. Walter said he preferred the second sentence. Ambrish said that he preferred the first one and that if they're equivalent, he prefers the first sentence because it's simpler. Walter said he was okay deleting the second sentence and keeping the first, as long as it's on the record that they are considered equivalent. Randy, Fangyi, and Arpad suggested other editorial corrections, and Ambrish updated the document. Arpad asked if this version could be summarized in the following way: DC_Offset is an In parameter, and NRZ_Threshold has been removed. Ambrish agreed, and Randy noted that this version was simple. Ambrish moved to submit the modified version to the Open Forum as BIRD197.5. Walter seconded. There were no objections. Ambrish agreed to send the proposal to Randy, and Randy agreed to notify the Open Forum and officially post the BIRD. Enabling Back-channel in Statistical Mode: Walter reviewed his first draft of a BCI Statistical Training BIRD. He noted that he thought people had preferred to iterate with AMI_Init() rather than add a new AMI_Impulse() function. Arpad said he wasn't sure anyone had expressed a real preference yet. Mike L. had suggested a way we might iterate with AMI_Init(), and Radek had agreed with Mike's suggestion. Walter said the proposal could easily be modified if we decided to go with a new AMI_Impulse() function instead. Walter reviewed the proposed spec changes: - New BCI_Training_Mode reserved parameter. - Allowed values of "Init", "GetWave" or "Dual" - Iterate with AMI_Init(). - Value pointed to by AMI_memory_handle indicates whether this is the initial call to AMI_Init() or not. - Flow keeps iterating between calls to Tx and Rx AMI_Init() until the value of BCI_State returned by the Rx AMI_Init() is "Converged". - Flow for repeaters has not been fully addressed yet (will be added). Arpad asked what the functional reason for adding an AMI_Impulse() would be. Walter said we could do everything by iterating with the existing AMI_Init(). If we did that, the contents of AMI_memory_handle would be null the first time AMI_Init() was called and would contain the value returned by the model on subsequent calls. As long as we accept that newly added purpose for AMI_memory_handle, everything can be done by iterating AMI_Init(). Walter noted, however, that previous proposals to overload existing function arguments had been rejected. He noted, for example, that a proposal to pass parameter values into AMI_GetWave() using the ami_parameters_out argument had not been well received. Michael M. asked if this was part of an historical correction in that AMI_Init() was originally designed only for set-up and initialization, and IR processing for statistical flow had been added later. Walter said this was not true. He noted that AMI_Init() had always been expected to work with the channel IR. He noted that the Tx AMI_Init() had taken an IR for the channel so the Tx could optimize itself for performance at the Rx pad. Statistical analysis and processing had always been part of AMI_Init(). Arpad noted that earlier discussions on improving the Redriver Init Flow had also considered the possibility of calling AMI_Init() multiple times. He asked if this might be a good time to consider separating signal processing from AMI_Init() and leaving AMI_Init() to focus purely on set-up and initialization. Ambrish asked if, instead of overloading AMI_Init(), we could instead override AMI_GetWave() and introduce a switch that lets the EDA tool iterate AMI_GetWave() with IRs instead of waveforms. He noted that the flow being introduced here for iterating AMI_Init() was identical to the AMI_GetWave() training flow that already existed. Walter agreed the flows were similar, but he asked Ambrish how you would tell AMI_GetWave() that you were passing it IRs instead of waveforms. Arpad said that in the past many members seemed to have preferred adding new functions instead of overloading existing ones, even if there was a certain amount of overlap. Walter said he would clean up the draft, add more to the repeater flow, and send it to the ATM list again. He noted that the fundamental question is still what function we will use to iterate in statistical training mode. - Michael M.: Motion to adjourn. - Randy: Second. - Arpad: Thank you all for joining. AR: Walter to send the latest BIRD198 syntax and examples proposal to Bob, Randy, Arpad, and Mike L. AR: Randy to draft a new response to the BIRD198 authors. AR: Ambrish to send the BIRD197.5 proposal to Randy. AR: Randy to notify the Open Forum and post BIRD197.5. AR: Walter to send out draft 2 of the BCI for Statistical BIRD. ------------- Next meeting: 22 October 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives